Rust y WebAssembly, el motor oculto de las apps rápidas

Cada vez más aplicaciones que parecen hechas en JavaScript esconden el trabajo pesado en módulos de Rust compilados a WebAssembly (Wasm). La interfaz sigue siendo React, HTML o una webview de escritorio, pero el análisis de ficheros grandes, la compresión, el renderizado o el parseo se ejecutan en un binario portátil, aislado y bastante más rápido. El desarrollador Jesús Pérez Mojica lo describía en un artículo reciente en Medium como el «backend secreto» de las aplicaciones de alto rendimiento. Repasamos qué hay detrás de esa idea, qué datos la sostienen y dónde sigue teniendo límites.

Las claves en 20 segundos

• El patrón: la interfaz se queda en JavaScript y la parte crítica se mueve a Wasm; no se reescribe toda la aplicación.
• Por qué ahora: WebAssembly 3.0 se publicó en septiembre de 2025 y el soporte en navegadores ronda el 95 % del uso mundial.
• Dónde ya se usa: navegador, edge (Cloudflare Workers), apps de escritorio con Tauri y sistemas de plugins.
• El límite: cruzar constantemente la frontera entre JavaScript y Wasm se come la ganancia; rinde en cálculo denso, no en todo.

Una capa que el usuario no ve

WebAssembly nació para complementar a JavaScript, no para sustituirlo. Así lo plantea la documentación de MDN, y así lo vende el propio proyecto Rust, que anima a mejorar el código JavaScript existente módulo a módulo. El resultado es una división de trabajo que se repite en muchos productos: una «carcasa» en la que se itera rápido y es fácil contratar, y un «núcleo» en el que importan la corrección, la portabilidad, el aislamiento y la velocidad.

Para un administrador de sistemas, ese núcleo no siempre vive en un servidor clásico. Puede ser un módulo que se ejecuta dentro de la pestaña del navegador, el motor de una aplicación de escritorio o una función desplegada en el edge. Lo que tienen en común es que el usuario solo percibe que la aplicación abre rápido, procesa ficheros grandes sin bloquearse y no se pelea con el navegador.

Por qué ahora tiene sentido

Hace unos años, Wasm parecía un experimento. Hoy es infraestructura. El grupo de trabajo de WebAssembly publicó la versión 3.0 del estándar en septiembre de 2025, con novedades largamente esperadas: espacio de direcciones de 64 bits, varias memorias por módulo, recolección de basura, gestión de excepciones y SIMD relajado. Los principales navegadores ya la implementan y, según Can I Use, el soporte de WebAssembly cubre en torno al 95 % del uso mundial de navegadores.

Fuera del navegador, el ecosistema también ha madurado. WASI, la interfaz estándar para ejecutar Wasm en servidores, edge y dispositivos, tiene una versión estable 0.2 basada en el Component Model de la Bytecode Alliance, que define cómo combinar módulos escritos en distintos lenguajes. La siguiente iteración añade soporte asíncrono nativo, una pieza clave para servicios de red; lo vimos en detalle en nuestro artículo sobre WASI 0.3 y el Component Model. No es un ecosistema terminado, pero ya no es un truco de navegador.

Por qué Rust encaja tan bien

Rust no tiene runtime ni recolector de basura, y su modelo de propiedad garantiza la seguridad de memoria y de hilos en tiempo de compilación. Esas propiedades encajan con lo que pide Wasm: código compacto, determinista y portátil que se ejecuta en un entorno aislado. Un binario sin recolector pesa menos y arranca antes, y los errores de memoria que en C o C++ acaban en vulnerabilidades se detectan antes de llegar a producción.

La cadena de herramientas también ayuda. wasm-bindgen genera los enlaces entre Rust y JavaScript, solo para lo que se usa, y wasm-pack empaqueta el resultado para el navegador o Node.js. Un flujo básico se parece a esto (hay una guía completa en Rust para WebAssembly: wasm-pack, wasm-bindgen y llamar a Rust desde JavaScript):

cargo install wasm-pack
cargo new --lib motor
cd motor
# en Cargo.toml: crate-type = ["cdylib"] y dependencia wasm-bindgen
wasm-pack build --target web --release
# el directorio pkg/ contiene el .wasm y el módulo JS listo para importar

Los números: reales, pero no mágicos

Los casos más citados son antiguos, pero siguen siendo los mejor documentados. Figma explicó en 2017 que pasar su motor a WebAssembly redujo el tiempo de carga a menos de un tercio, con independencia del tamaño del documento. Mozilla reescribió en 2018 la parte más crítica de su parser de source maps en Rust compilado a Wasm y obtuvo mejoras de hasta 5,89 veces en pruebas realistas, que tras optimizaciones adicionales del algoritmo llegaron hasta 10,9 veces. Su conclusión fue que habían sustituido JavaScript enrevesado, escrito para exprimir rendimiento, por Rust idiomático que además era más rápido.

Fuera del navegador, los estudios académicos sobre serverless en el edge apuntan en la misma dirección, con matices: las imágenes Wasm compiladas por adelantado pueden ser mucho más pequeñas que un contenedor y arrancar en frío más rápido, pero el Wasm interpretado puede rendir peor una vez caliente y con mucha entrada/salida. La ganancia depende de la carga: es grande cuando se mueve un bloque de cálculo pesado y pequeña, o negativa, si se recompila media interfaz sin criterio.

Más allá de la pestaña del navegador

• Edge: Cloudflare Workers permite escribir funciones completas en Rust con el crate worker, que se compilan a Wasm y se ejecutan sobre el motor V8, cerca del usuario.
• Escritorio y móvil: Tauri 2.0 crea aplicaciones para Linux, macOS, Windows, Android e iOS con la interfaz en la webview del sistema y el núcleo en Rust. El proyecto habla de binarios de apenas 600 KB, frente a los cientos de megas de una app con Electron.
• Interfaces en Rust: frameworks como Leptos, Dioxus o Yew permiten escribir también la interfaz en Rust, con renderizado en servidor e hidratación.
• Plugins y dispositivos: WASI se propone para sistemas de plugins aislados y para dispositivos con recursos limitados, donde la portabilidad y el aislamiento pesan más que exprimir cada ciclo.

Un ejemplo cercano: PDFs que nunca salen del equipo

En Color Vivo, la editora de este medio, usamos este patrón en proyectos propios. files.co y reader.me ofrecen más de 30 herramientas para PDF (unir, dividir, comprimir, firmar, rellenar formularios, OCR, convertir a PDF/A o eliminar contenido activo) que se ejecutan por completo en el navegador mediante WebAssembly. El fichero no se sube a ningún servidor, algo que cualquiera puede comprobar en la pestaña de red de las herramientas de desarrollo, y reader.me funciona incluso sin conexión como aplicación web instalable. El OCR, por ejemplo, se hace en local con Tesseract compilado a Wasm.

Es el caso de uso donde Wasm marca más diferencia: procesar datos sensibles, como contratos, nóminas o documentos de identidad, sin el riesgo y la responsabilidad legal de almacenarlos en un servidor ajeno. Para un administrador, además, desaparece la necesidad de mantener un backend que reciba y procese esos ficheros.

Rust también sirve fuera de Wasm, en herramientas nativas para sistemas. mboxShell (lo contamos aquí), otro proyecto nuestro de código abierto, es un visor de ficheros MBOX para terminal escrito en Rust que abre buzones de más de 50 GB con un parser en streaming y un índice persistente, y se distribuye como binario único para Linux (x86_64, ARM64 y RISC-V), FreeBSD, macOS y Windows; ya recibe contribuciones de terceros y está empaquetado en distribuciones como NixOS. Y CrawlForge es un rastreador SEO de código abierto en Rust, con licencia Apache 2.0, que guarda los resultados en SQLite, compara rastreos entre sí y aplica decenas de reglas de auditoría sin depender de Java ni de un navegador.

Las pegas que siguen ahí

WebAssembly no elimina a JavaScript. Para crear nodos del DOM o abrir conexiones de red, un módulo Wasm sigue teniendo que llamar a JavaScript, como reconocía el propio equipo de Figma. Y esa frontera tiene un coste: Mozilla movió todo el proceso de parseo a Wasm, en lugar de portar funciones sueltas, precisamente porque cada cruce entre ambos mundos añade sobrecarga. El punto óptimo está en tareas que pueden quedarse un buen rato dentro de Wasm: parseo, simulación, códecs, compresión, transformaciones de imágenes o documentos.

Hay también limitaciones de plataforma. El objetivo wasm32-unknown-unknown de Rust es mínimo a propósito: println! no hace nada, std::fs devuelve errores y std::thread::spawn provoca un pánico. Para acceder al sistema hay que usar los objetivos WASI, como wasm32-wasip1 o wasm32-wasip2:

rustup target add wasm32-wasip2
cargo build --target wasm32-wasip2 --release
wasmtime target/wasm32-wasip2/release/app.wasm

Y hay que contar con la depuración, que sigue siendo más incómoda que en JavaScript, y con el peso del binario si no se optimiza (opt-level = "z", LTO y herramientas como wasm-opt). Nada de esto invalida el patrón, pero conviene saberlo antes de proponerlo en un equipo.

La apuesta realista

La lectura sensata no es «reescribir la web en Rust», sino identificar la parte de una aplicación que es lenta, sensible a la memoria o difícil de confiar, y moverla a un núcleo en Rust compilado a Wasm. Es la misma lógica que ha llevado a Rust al núcleo de Linux, donde ya es parte permanente del kernel, aunque en el navegador no siempre compense: hay proyectos que eligen expresamente no usar Wasm, como JSQLite, que lleva SQLite al navegador en TypeScript puro. Si el patrón sigue extendiéndose, los usuarios no sabrán que están usando Rust. Solo notarán que la aplicación carga antes, aguanta ficheros más grandes y falla menos.

Preguntas frecuentes

¿WebAssembly sustituye a JavaScript?
No. Está diseñado para complementarlo. JavaScript sigue gestionando la interfaz, el DOM y la red, mientras Wasm se encarga de las tareas de cálculo intensivo.

¿Por qué se usa tanto Rust para WebAssembly?
Porque no tiene recolector de basura ni runtime, genera binarios compactos y garantiza la seguridad de memoria en compilación. Además cuenta con herramientas maduras como wasm-bindgen y wasm-pack.

¿Siempre es más rápido usar Wasm?
No. Rinde en cálculo denso que se queda dentro del módulo. Si el código cruza constantemente la frontera con JavaScript, la sobrecarga puede anular la ganancia.

¿Se puede usar WebAssembly fuera del navegador?
Sí. Con WASI y runtimes como Wasmtime se ejecuta en servidores, en el edge (por ejemplo, Cloudflare Workers), en sistemas de plugins y en dispositivos embebidos.

Fuente: Jesús Pérez Mojica en Medium, a partir de la documentación de WebAssembly, Rust, MDN, Figma, Mozilla, Cloudflare y Tauri.

Imagen: Pexels / Alex Tepetidis